fix(a11y): composite alpha when measuring contrast ratios - #122

The compositing fix itself is right: f.a * v + (1 - f.a) * b.rgb[i] is proper source-over, the ~2.62 expectation computes to 2.6179 (comfortably inside toBeCloseTo(2.62, 1)), and none of the three existing product assertions change — hero-cta, event-bar-cta, and the nav pill are all opaque text-brand-dark on bg-brand-pink/bg-accent-400, so the suite stays green on that front.

Requesting changes on one blocker: the branch fails npm run format:check, which .github/workflows/ci.yml:37 runs as a required step, so this lands red as-is.

Beyond that, the comments below are mostly about the helper reporting a passing ratio for a pairing that genuinely fails. I know the PR body defers semi-transparent backgrounds to a follow-up, and that's a fair scope call — my ask is only that the deferral be loud (throw) rather than silent (green check), so we don't bank confidence on measurements the helper can't actually make yet.

One more, outside the diff — effectiveColours, line 67

GitHub won't let me anchor an inline comment there since it's untouched by this PR, so it goes here.

isTransparent only rejects alpha === 0, so the walk-up stops at the first partially transparent ancestor and hands its raw RGB back as both the composite base and the background luminance. Concrete case: dark text over a bg-white/10 veil on the dark page measures 17.40:1 — passes AA comfortably — when the real composited ratio is 1.34:1.

This isn't hypothetical for the current DOM: src/components/Header.astro:168 uses bg-brand-dark/90.

Deferring full background compositing is fine, but as written the helper manufactures a passing number instead of declining to measure. Minimum viable version — keep climbing when the background isn't opaque, or throw:

const a = alpha && alpha.length === 4 ? Number(alpha[3]) : 1;
if (a > 0 && a < 1) {
  throw new Error(`translucent background ${bg} on <${node.tagName}> — not yet supported`);
}

Thanks for taking #117 — the core compositing fix is right. I ran the new helper standalone and both new assertions hold (6.396487 vs toBeCloseTo(6.3965, 3), and 2.61796 vs ~2.62), and the opaque path is numerically identical to the old parseRgb, so there's no regression on the existing tests.

Two things to fix before merge — one real, one latent. Details inline.